Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.161 < prev next >

Wrap

Text File | 1996-02-12 | 27.9 KB | 656 lines

Frequently Asked Questions (FAQS);faqs.161 RICHARD SWINBURNE "The Existence of God (Revised Edition)", Clarendon Paperbacks, Oxford This book is the second volume in a trilogy that began with "The Coherence of Theism" (1977) and was concluded with "Faith and Reason" (1981). In this work, Swinburne attempts to construct a series of inductive arguments for the existence of God. His arguments, which are somewhat tendentious and rely upon the imputation of late 20th century western Christian values and aesthetics to a God which is supposedly as simple as can be conceived, were decisively rejected in Mackie's "The Miracle of Theism". In the revised edition of "The Existence of God", Swinburne includes an Appendix in which he makes a somewhat incoherent attempt to rebut Mackie. J. L. MACKIE "The Miracle of Theism", Oxford This (posthumous) volume contains a comprehensive review of the principal arguments for and against the existence of God. It ranges from the classical philosophical positions of Descartes, Anselm, Berkeley, Hume et al, through the moral arguments of Newman, Kant and Sidgwick, to the recent restatements of the classical theses by Plantinga and Swinburne. It also addresses those positions which push the concept of God beyond the realm of the rational, such as those of Kierkegaard, Kung and Philips, as well as "replacements for God" such as Lelie's axiarchism. The book is a delight to read - less formalistic and better written than Martin's works, and refreshingly direct when compared with the hand-waving of Swinburne. JAMES A. HAUGHT "Holy Horrors: An Illustrated History of Religious Murder and Madness", Prometheus Books Looks at religious persecution from ancient times to the present day -- and not only by Christians. Library of Congress Catalog Card Number 89-64079. 1990. NORM R. ALLEN, JR. "African American Humanism: an Anthology" See the listing for African Americans for Humanism above. GORDON STEIN "An Anthology of Atheism and Rationalism", Prometheus Books An anthology covering a wide range of subjects, including 'The Devil, Evil and Morality' and 'The History of Freethought'. Comprehensive bibliography. EDMUND D. COHEN "The Mind of The Bible-Believer", Prometheus Books A study of why people become Christian fundamentalists, and what effect it has on them. Net Resources There's a small mail-based archive server at mantis.co.uk which carries archives of old alt.atheism.moderated articles and assorted other files. For more information, send mail to archive-server@mantis.co.uk saying help send atheism/index and it will mail back a reply. mathew Xref: bloom-picayune.mit.edu alt.binaries.sounds.misc:3805 alt.binaries.sounds.d:1998 comp.dsp:4887 news.answers:4659 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!ira.uka.de!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!news.netmbx.de!Germany.EU.net!mcsun!sun4nl!cwi.nl!guido From: guido@cwi.nl (Guido van Rossum) Newsgroups: alt.binaries.sounds.misc,alt.binaries.sounds.d,comp.dsp,news.answers Subject: Changes to: FAQ: Audio File Formats (version 2.9) Message-ID: <audio-diff_724600938@charon.cwi.nl> Date: 17 Dec 92 14:02:47 GMT Expires: 14 Jan 93 14:02:18 GMT Sender: news@cwi.nl Reply-To: guido@cwi.nl Followup-To: alt.binaries.sounds.d,comp.dsp Lines: 101 Approved: news-answers-request@MIT.Edu Supersedes: <audio-diff_722270826@charon.cwi.nl> Archive-name: audio-fmts/diff Submitted-by: Guido van Rossum <guido@cwi.nl> Version: 2.9 Last-modified: 17-Dec-1992 *** A2.8 Fri Nov 20 15:45:24 1992 --- A2.9 Thu Dec 17 15:00:59 1992 *************** *** 46,47 **** --- 46,48 ---- U-LAW and A-LAW definitions + AVR File Format *************** *** 68,69 **** --- 69,76 ---- + NEWSFLASH: This FAQ is now also available in distributed hypertext + form! If you have a WWW browser and direct Internet access you can + point it to "http://voorn.cwi.nl/audio-formats/a00.html". (WWW is the + CERN World-Wide Web initiative; for more info, telnet or ftp to + info.cern.ch.) + Send updates, comments and questions to <guido@cwi.nl>; flames to *************** *** 156,158 **** rate; the latter is precisely 22254.545454545454 but ! usually misquoted as 22000. --- 163,167 ---- rate; the latter is precisely 22254.545454545454 but ! usually misquoted as 22000. (Historical note: ! 22254.5454... was the horizontal scan rate of the ! original 128k Mac.) *************** *** 208,210 **** 32 kbits/sec ADPCM algorithm is available by ftp from ftp.cwi.nl as ! /pub/adpcm.shar. --- 217,221 ---- 32 kbits/sec ADPCM algorithm is available by ftp from ftp.cwi.nl as ! /pub/adpcm.shar. (** NOTE: if you are using v1.0, you should get ! v1.1, released 17-Dec-1992, which fixes a serious bug -- the quality ! of v1.1 is claimed to be better than uLAW **) *************** *** 270,271 **** --- 281,283 ---- Atari STe,TT 8 50k 2 + Atari Falcon 030 16 50k 8(st) Amiga 8 ~29k 4(st) *************** *** 306,307 **** --- 318,326 ---- + Here's some info about the newest Atari machine, the Falcon030. This + machine has stereo 16 bit CODECs and a 32 MHz Motorola 56001 that can + handle 8 channels of 16 bit audio, up to 50 khz/channel with + simultaneous playback and record. The Falcon DMA sound engine is also + compatible with the 8 bit stereo DMA used on the STe and TT. All of + these systems use signed data. + On the NeXT, the Motorola 56001 DSP chip is programmable and you can *************** *** 1477,1478 **** --- 1496,1529 ---- + ------------------------------------------------------------------------ + AVR File Format + --------------- + + From: hyc@hanauma.Jpl.Nasa.Gov (Howard Chu) + + A lot of PD software exists to play Mac .snd files on the ST. One other + format that seems pretty popular (used by a number of commercial packages) + is the AVR format (from Audio Visual Research). This format has a 128 byte + header that looks like this: + + char magic[4]="2BIT"; + char name[8]; /* null-padded sample name */ + short mono; /* 0 = mono, 0xffff = stereo */ + short rez; /* 8 = 8 bit, 16 = 16 bit */ + short sign; /* 0 = unsigned, 0xffff = signed */ + short loop; /* 0 = no loop, 0xffff = looping sample */ + short midi; /* 0xffff = no MIDI note assigned, + 0xffXX = single key note assignment + 0xLLHH = key split, low/hi note */ + long rate; /* sample frequency in hertz */ + long size; /* sample length in bytes or words (see rez) */ + long lbeg; /* offset to start of loop in bytes or words. + set to zero if unused. */ + long lend; /* offset to end of loop in bytes or words. + set to sample length if unused. */ + short res1; /* Reserved, MIDI keyboard split */ + short res2; /* Reserved, sample compression */ + short res3; /* Reserved */ + char ext[20]; /* Additional filename space, used + if (name[7] != 0) */ + char user[64]; /* User defined. Typically ASCII message. */ ------------------------------------------------------------------------ Xref: bloom-picayune.mit.edu alt.binaries.sounds.misc:3804 alt.binaries.sounds.d:1997 comp.dsp:4886 news.answers:4658 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sun4nl!cwi.nl!guido From: guido@cwi.nl (Guido van Rossum) Newsgroups: alt.binaries.sounds.misc,alt.binaries.sounds.d,comp.dsp,news.answers Subject: FAQ: Audio File Formats (version 2.9) Message-ID: <audio-fmts_724600938@charon.cwi.nl> Date: 17 Dec 92 14:02:32 GMT Expires: 14 Jan 93 14:02:18 GMT Sender: news@cwi.nl Reply-To: guido@cwi.nl Followup-To: alt.binaries.sounds.d,comp.dsp Lines: 1518 Approved: news-answers-request@MIT.Edu Supersedes: <audio-fmts_722270826@charon.cwi.nl> Archive-name: audio-fmts/part1 Submitted-by: Guido van Rossum <guido@cwi.nl> Version: 2.9 Last-modified: 17-Dec-1992 FAQ: Audio File Formats (version 2.9) ===================================== Table of contents ----------------- Introduction Device characteristics Popular sampling rates Compression schemes Current hardware File formats File conversions Playing audio files on UNIX Playing audio files on micros The Sound Site Newsletter Posting sounds Appendices: FTP access for non-internet sites AIFF Format (Audio IFF) The NeXT/Sun audio file format IFF/8SVX Format Playing sound on a PC The EA-IFF-85 documentation US Federal Standard 1016 availability Creative Voice (VOC) file format RIFF WAVE (.WAV) file format U-LAW and A-LAW definitions AVR File Format Introduction ------------ This is version 2 of this FAQ, which I started in November 1991 under the name "The audio formats guide". I bumped the major version number since the Subject and Newsgroups headers have changed to make the subject more informative and give the guide a wider audience. I also added a Table of contents section at the top. I am posting this about once a fortnight, either unchanged (just to inform new readers), or updated (if I learn more or when new hardware or software becomes popular). I post to alt.binaries.sounds.{misc,d} and to comp.dsp, for maximal coverage of people interested in audio, and to news.answers, for easy reference. A companion posting with subject "Change to: ..." is occasionally posted listing the diffs between a new version and the last. This is not reposted, and it is suppressed when the diffs are bigger than the new version. NEWSFLASH: This FAQ is now also available in distributed hypertext form! If you have a WWW browser and direct Internet access you can point it to "http://voorn.cwi.nl/audio-formats/a00.html". (WWW is the CERN World-Wide Web initiative; for more info, telnet or ftp to info.cern.ch.) Send updates, comments and questions to <guido@cwi.nl>; flames to /dev/null. I'd like to thank everyone who sent me mail with updates for previous versions. The list of names is really too long to list you all... --Guido van Rossum, CWI, Amsterdam <guido@cwi.nl> "Lobster thermidor aux crevettes with a mornay sauce garnished with truffle pate, brandy and a fried egg on top and spam" Device characteristics ---------------------- In this text, I will only use the term "sample" to refer to a single output value from an A/D converter, i.e., a small integer number (usually 8 or 16 bits). Audio data is characterized by the following parameters, which correspond to settings of the A/D converter when the data was recorded. Naturally, the same settings must be used to play the data. - sampling rate (in samples per second), e.g. 8000 or 44100 - number of bits per sample, e.g. 8 or 16 - number of channels (1 for mono, 2 for stereo, etc.) Approximate sampling rates are often quoted in Hz or kHz ([kilo-] Hertz), however, the politically correct term is samples per second (samples/sec). Sampling rates are always measured per channel, so for stereo data recorded at 8000 samples/sec, there are actually 16000 samples in a second. I will sometimes write 8 k as a shorthand for 8000 samples/sec. Multi-channel samples are generally interleaved on a frame-by-frame basis: if there are N channels, the data is a sequence of frames, where each frame contains N samples, one from each channel. (Thus, the sampling rate is really the number of *frames* per second.) For stereo, the left channel usually comes first. The specification of the number of bits for U-LAW (pronounced mu-law -- the u really stands for the Greek letter mu) samples is somewhat problematic. These samples are logarithmically encoded in 8 bits, like a tiny floating point number; however, their dynamic range is that of 14 bit linear data. Source for converting to/from U-LAW (written by Jef Poskanzer) is distributed as part of the SOX package mentioned below; it can easily be ripped apart to serve in other applications. The official definition is the CCITT standard G.711. There exists another encoding similar to U-LAW, called A-LAW, which is used as a European telephony standard. There is less support for it in UNIX workstations. (See the Appendix for some formulae describing U-LAW and A-LAW.) Popular sampling rates ---------------------- Some sampling rates are more popular than others, for various reasons. Some recording hardware is restricted to (approximations of) some of these rates, some playback hardware has direct support for some. The popularity of divisors of common rates can be explained by the simplicity of clock frequency dividing circuits :-). Samples/sec Description 5500 One fourth of the Mac sampling rate (rarely seen). 7333 One third of the Mac sampling rate (rarely seen). 8000 Exactly 8000 samples/sec is a telephony standard that goes together with U-LAW (and also A-LAW) encoding. Some systems use an slightly different rate; in particular, the NeXT workstation uses 8012.8210513, apparently the rate used by Telco CODECs. 11 k Either 11025, a quarter of the CD sampling rate, or half the Mac sampling rate (perhaps the most popular rate on the Mac). 16000 Used by, e.g. the G.722 compression standard. 18.9 k CD-ROM/XA standard. 22 k Either 22050, half the CD sampling rate, or the Mac rate; the latter is precisely 22254.545454545454 but usually misquoted as 22000. (Historical note: 22254.5454... was the horizontal scan rate of the original 128k Mac.) 32000 Used in digital radio, NICAM (Nearly-Instantaneous Companded Audio Multiplex [IBA/BREMA/BBC]) and other TV work, at least in the UK; also long play DAT and Japanese HDTV. 37.8 k CD-ROM/XA standard for higher quality. 44056 This weird rate is used by professional audio equipment to fit an integral number of samples in a video frame. 44100 The CD sampling rate. (DAT players recording digitally from CD also use this rate.) 48000 The DAT (Digital Audio Tape) sampling rate for domestic use. Files samples on SoundBlaster hardware have sampling rates that are divisors of 1000000. While professinal musicians disagree, most people don't have a problem if recorded sound is played at a slightly different rate, say, 1-2%. On the other hand, if recorded data is being fed into a playback device in real time (say, over a network), even the smallest difference in sampling rate can frustrate the buffering scheme used... There may be an emerging tendency to standardize on only a few sampling rates and encoding styles, even if the file formats may differ. The suggested rates and styles are: rate (samp/sec) style mono/stereo 8000 8-bit U-LAW mono 22050 8-bit linear unsigned mono and stereo 44100 16-bit linear signed mono and stereo Compression schemes ------------------- Strange though it seems, audio data is remarkably hard to compress effectively. For 8-bit data, a Huffman encoding of the deltas between successive samples is relatively successful. For 16-bit data, companies like Sony and Philips have spent millions to develop proprietary schemes. Public standards for voice compression are slowly gaining popularity, e.g. CCITT G.721 and G.723 (ADPCM at 32 and 24 kbits/sec). (ADPCM == Adaptive Delta Pulse Code Modulation.) Free source code for a *fast* 32 kbits/sec ADPCM algorithm is available by ftp from ftp.cwi.nl as /pub/adpcm.shar. (** NOTE: if you are using v1.0, you should get v1.1, released 17-Dec-1992, which fixes a serious bug -- the quality of v1.1 is claimed to be better than uLAW **) There are also two US federal standards, 1016 (Code excited linear prediction (CELP), 4800 bits/s) and 1015 (LPC-10E, 2400 bits/s). See also the appendix for 1016. (Note that U-LAW and silence detection can also be considered compression schemes.) Here's a note about audio codings by Van Jacobson <van@ee.lbl.gov>: Several people used the words "LPC" and "CELP" interchangably. They are very different. An LPC (Linear Predictive Coding) coder fits speech to a simple, analytic model of the vocal tract, then throws away the speech & ships the parameters of the best-fit model. An LPC decoder uses those parameters to generate synthetic speech that is usually more-or-less similar to the original. The result is intelligible but sounds like a machine is talking. A CELP (Code Excited Linear Predictor) coder does the same LPC modeling but then computes the errors between the original speech & the synthetic model and transmits both model parameters and a very compressed representation of the errors (the compressed representation is an index into a 'code book' shared between coders & decoders -- this is why it's called "Code Excited"). A CELP coder does much more work than an LPC coder (usually about an order of magnitude more) but the result is much higher quality speech: The FIPS-1016 CELP we're working on is essentially the same quality as the 32Kb/s ADPCM coder but uses only 4.8Kb/s (the same as the LPC coder). Finally, the comp.compression FAQ has some text on the 6:1 audio compression scheme used by MPEG (a video compression standard-to-be). It's interesting to note that video compression reaches much higher ratios (like 26:1). This FAQ is ftp'able from rtfm.mit.edu [18.72.1.58] in directory /pub/usenet/news.answers/compression-faq, files part1 and part2. Comp.compression also carries a regular posting "How to uncompress anything" by David Lemson <lemson@uiuc.edu>, which (tersely) hints on which program you need to uncompress a file whose name ends in .<foo> for almost any conceivable <foo>. Ftp'able from ftp.cso.uiuc.edu (128.174.5.59) in the directory /doc/pcnet as the file compression. Current hardware ---------------- I am aware of the following computer systems that can play back and (sometimes) record audio data, with their characteristics. Note that for most systems you can also buy "professional" sampling hardware, which supports much better quality, e.g. >= 44.1 k 16 bits stereo. The characteristics listed here are a rough estimate of the capabilities of the basic hardware only (and even here I am on thin ice, with systems becoming ever more powerful). machine bits max sampling rate #output channels Mac 8 22k 1 Apple IIgs 8 32k / >70k 8(st) PC/Soundblaster v1 8 13k / 22k 1 PC/Soundblaster v2 8 15k / 44.1k 1 PC/PAS-16 16 44.1k ?(st) Atari ST 8 22k 1 Atari STe,TT 8 50k 2 Atari Falcon 030 16 50k 8(st) Amiga 8 ~29k 4(st) Sun Sparc U-LAW 8k 1 Sun Sparcst. 10 U-LAW,8,16 48k 1(st) NeXT U-LAW,8,16 44.1k 1(st) SGI Indigo 8,16 48k 4(st) Acorn Archimedes ~U-LAW ~180k 8(st) Sony RISC-NEWS 8, 16 37.8k ?(st) VAXstation 4000 U-LAW 8k 1 Tandy 1000/*L* 8-bit 22k 3 4(st) means "four voices, stereo"; sampling rates xx/yy are different recording/playback rates; *L* is any type with 'L' in it. All these machines can play back sound without additional hardware, although the needed software is not always standard; only the Sun, NeXT and SGI come with standard sampling hardware (the NeXT only samples U-LAW at 8000 samples/sec from the built-in microphone port; you need a separate board for other rates). The new VAXstation 4000 (VLC and model 60) series lets you PLAY audio (.au) files, and the package DECsound will let you do the recording. In fact, DECsound is given away free with Motif 1.1 and supports the VAXstation, Sun SPARCstation, DECvoice, and XMedia audio devices. Sun sound files work without change. The SGI Personal IRIS 4D/30 and 4D/35 have the same capabilities as the Indigo. The new Apple Macs have more powerful audio hardware; the latest models have built-in microphones. Software exists for the PC that can play sound on its 1-bit speaker using pulse width modulation (see appendix); the Soundblaster board records at rates up to 13 k and plays back up to 22 k (weird combination, but that's the way it is). Here's some info about the newest Atari machine, the Falcon030. This machine has stereo 16 bit CODECs and a 32 MHz Motorola 56001 that can handle 8 channels of 16 bit audio, up to 50 khz/channel with simultaneous playback and record. The Falcon DMA sound engine is also compatible with the 8 bit stereo DMA used on the STe and TT. All of these systems use signed data. On the NeXT, the Motorola 56001 DSP chip is programmable and you can (in principle) do what you want. The SGI uses the same DSP chip but it can't be programmed by users -- SGI prefers to offer it as a shared system resource to multiple applications, thus enabling developers to program audio with their Audio Library and avoid code modifications for execution on future machines with different audio hardware, i.e. a different DSP. The Amiga also has a 6-bit volume, which can be used to produce something like a 14-bit output for each voice. The hardware can also use one of each voice-pair to modulate the other in FM (period) or AM (volume, 6-bits). The Acorn Archimedes uses a variation on U-LAW with the bit order reversed and the sign bit in bit 0. Being a 'minority' architecture, Arc owners are quite adept at converting sound/image formats from other machines, and it is unlikely that you'll ever encounter sound in one of the Arc's own formats (there are several). CD-I machines form a special category. The following formats are used: - PCM 44.1 kHz standard CD format - ADPCM - Addaptive Delta PCM - Level A 37.8 kHz 8-bit - Level B 37.8 kHz 4-bit - Level C 18.9 kHz 4-bit File formats ------------ Historically, almost every type of machine used its own file format for audio data, but some file formats are more generally applicable, and in general it is possible to define conversions between almost any pair of file formats -- sometimes losing information, however. File formats are a separate issue from device characteristics. There are two types of file formats: self-describing formats, where the device parameters and encoding are made explicit in some form of header, and "raw" formats, where the device parameters and encoding are fixed. Self-describing file formats generally define a family of data encodings, where a header fields indicates the particular encoding variant used. Headerless formats define a single encoding and usually allows no variation in device parameters (except sometimes sampling rate, which can be a pain to figure out other than by listening to the sample). The header of self-describing formats contains the parameters of the sampling device and sometimes other information (e.g. a human-readable description of the sound, or a copyright notice). Most headers begin with a simple "magic word". (Some formats do not simply define a header format, but may contain chunks of data intermingled with chunks of encoding info.) The data encoding defines how the actual samples are stored in the file, e.g. signed or unsigned, as bytes or short integers, in little-endian or big-endian byte order, etc. Strictly spoken, channel interleaving is also part of the encoding, although so far I have seen little variation in this area. Some file formats apply some kind of compression to the data, e.g. Huffman encoding, or simple silence deletion. Here's an overview of popular file formats. Self-describing file formats ---------------------------- extension, name origin variable parameters (fixed; comments) .au or .snd NeXT, Sun rate, #channels, encoding, info string .aif(f), AIFF Apple, SGI rate, #channels, sample width, lots of info .aif(f), AIFC Apple, SGI same (extension of AIFF with compression) .iff, IFF/8SVX Amiga rate, #channels, instrument info (8 bits) .voc Soundblaster rate (8 bits/1 ch; can use silence deletion) .wav, WAVE Microsoft rate, #channels, sample width, lots of info .sf IRCAM rate, #channels, encoding, info none, HCOM Mac rate (8 bits/1 ch; uses Huffman compression) none, MIME Internet (see below) .mod or .nst Amiga (see below) Note that the filename extension ".snd" is ambiguous: it can be either the self-describing NeXT format or the headerless Mac/PC format, or even a headerless Amiga format. I know nothing for sure about the origin of HCOM files, only that there are a lot of them floating around on our system and probably at FTP sites over the world. The filenames usually don't have a ".hcom" extension, but this is what SOX (see below) uses. The file format recognized by SOX includes a MacBinary header, where the file type field is "FSSD". The data fork begins with the magic word "HCOM" and contains Huffman compressed data; after decompression it it is 8 bits unsigned data. IFF/8SVX allows for amplitude contours for sounds (attack/decay/etc). Compression is optional (and extensible); volume is variable; author, notes and copyright properties; etc. AIFF, AIFC and WAVE are similar in spirit but allow more freedom in encoding style (other than 8 bit/sample), amongst others. There are other sound formats in use on Amiga by digitizers and music programs, such as IFF/SMUS. Appendices describes the NeXT and VOC formats; pointers to more info about AIFF, AIFC, 8SVX and WAVE (which are too complex to describe here) are also in appendices. DEC systems (e.g. DECstation 5000) use a variant of the NeXT format that uses little-endian encoding and has a different magic number (0x0064732E in little-endian encoding). Standard file formats used in the CD-I world are IFF but on the disc they're in realtime files. An interesting "interchange format" for audio data is described in the proposed Internet Standard "MIME", which describes a family of transport encodings and structuring devices for electronic mail. This is an extensible format, and initially standardizes a type of audio data dubbed "audio/basic", which is 8-bit U-LAW data sampled at 8000 samples/sec. Finally, a format that doesn't really belong here are "MOD" files, usually with extension ".mod" or ".nst" (on PCs, that is -- on Amigas they have a *prefix* of "mod."). These files are short clips of sounds with sequencing information. This makes for fairly compact files but is limitted to making music with samples of a piano and trumpet, etc. Headerless file formats ----------------------- extension origin parameters or name .snd, .fssd Mac, PC variable rate, 1 channel, 8 bits unsigned .ul US telephony 8 k, 1 channel, 8 bit "U-LAW" encoding .snd? Amiga variable rate, 1 channel, 8 bits signed It is usually easy to distinguish 8-bit signed formats from unsigned by looking at the beginning of the data with 'od -b <file | head'; since most sounds start with a little bit of silence containing small amounts of background noise, the signed formats will have an abundance of bytes with values 0376, 0377, 0, 1, 2, while the unsigned formats will have 0176, 0177, 0200, 0201, 0202 instead. (Using "od -c" will also show any headers that are tacked in front of the file.)